Summary

Why this matters (business)

The Insights tab and any future log-driven dashboards are how operators tell "is my server healthy?" apart from "did a client send me a bad request?" Today, every non-streaming /chat/completions error is logged as 500 Internal Server Error, even when the user just asked for a model that isn't installed (404) or a remote provider is down (503). That mis-classification makes the metrics look like the server is on fire when it's actually a clean client- or config-level failure — exactly the noise PR osaurus-ai#863 set out to remove.

Same effect on the WorkView error classifier: it consumes Insights entries to give users actionable feedback ("install the model" vs "check your network"), and that classifier was already wired up correctly for the wire response — it just never saw the right status from the log.

What's wrong (technical)

The non-streaming handler maps ChatEngine.EngineError to its intended httpStatus and writes that to the wire:

                    let status: HTTPResponseStatus
                    let body: String
                    if let engineError = error as? ChatEngine.EngineError {
                        status = HTTPResponseStatus(statusCode: engineError.httpStatus)
                        body = engineError.errorDescription ?? error.localizedDescription
                    } else {
                        status = .internalServerError
                        body = "Internal error: \(error.localizedDescription)"
                    }
                    ...
                        var responseHead = HTTPResponseHead(version: head.version, status: status)

…but the Insights log call right below hardcoded responseStatus: 500:

                    logSelf.logRequest(
                        ...
                        responseStatus: 500,
                        ...
                    )

Fix

Use Int(status.code) so the log entry matches the wire status. One-line change, zero behaviour impact on actual responses; only Insights observability improves.

Out of scope (intentional): the streaming /chat/completions, /messages, and /responses error paths log 500. Those handlers commit the SSE 200 head before the failure happens or always reply 500 on the wire, so their log status already matches the wire reality. They can be revisited as a follow-up if/when those handlers gain EngineError-aware status mapping.

Changes

• Behavior change (observability only — wire response is unchanged)
• UI change
• Refactor / chore
• Tests (this is a pure log-string change; an end-to-end Insights test would require wiring InsightsService into HTTP handler tests, which is larger than the fix)
• Docs

Test Plan

1. Start the server, point a client at a model id that isn't installed: curl localhost:1234/v1/chat/completions -d '{"model":"nonexistent","messages":[{"role":"user","content":"hi"}]}'.
2. Wire response should be 404 (already correct).
3. Open Insights → request should now show 404 instead of 500.
4. Repeat with a remote provider in a disconnected state → should show 503.

Checklist

• I have read CONTRIBUTING.md
• I added/updated tests where reasonable (see "out of scope" above)
• I updated docs/README as needed (n/a)
• I verified build on macOS with Xcode 16.4+ (authored in a Linux CI sandbox)